When OASIS showed a payment that had not actually processed (a phantom card payment) the registration was cancelled, a credit note was raised to balance the invoice and a corrective refund ledger entry was posted to clear the false payment; for example a £223 refund was recorded using refund type "CORCRD", which flagged and removed the phantom payment from the ledger. In separate incidents where Stripe recorded a student as pay-in-full instead of on a monthly plan, staff attempted to use the "Strip C" correction in the Payment Refunds screen to switch the payment method to DPAYCO/DPAYIN but the operation was blocked when the refund amount exceeded the requestor's refund-permission limit. Those Stripe/pay-in-full cases therefore required finance-level intervention or alternative ledger adjustments (credit-note plus an authorised corrective refund) to correct the invoice and payment records.

Incidents involving Company Portal/Intune/MDM‑distributed applications were resolved by addressing faulty packages, device targeting/enrollment state, residual local state, authentication/entitlement blockers, and reprovisioning or restoring devices when corruption prevented recovery. Key observed fixes included:

Resolutions typically involved removing or replacing faulty update packages, ensuring targets were enrolled and online for MDM pushes, clearing residual/local state, resolving authentication or entitlement blockers, reprovisioning/approving apps to appropriate users or device groups, and performing complete reinstalls or device restores when corruption prevented recovery.

In one resolved case the device had been signed in with an institutional, email-based Apple ID that imposed App Store restrictions; a new Apple ID was created using a non‑institutional email address, the device was signed out of the institutional Apple ID and signed in with the new account, and the requested apps (Outlook, Teams, WhatsApp, etc.) downloaded successfully. In a separate matched case a new iPhone showed the App Store download/Get button as inactive/greyed out with no error codes; no confirmed fix was recorded for that instance and support noted standard troubleshooting (restarting the device and checking for iOS/App Store updates) without a verified resolution.

Microsoft Teams' built-in annotation feature was used while sharing the entire screen (annotation not available when sharing a single application window). When the full screen was shared the Teams top bar exposed a pen/annotation icon which entered annotation mode and allowed drawing/highlighting during the meeting.

A coordinated programme of targeted data fixes, configuration corrections, code changes and operational escalations resolved multiple defects affecting qualification, recertification and registration records. Key actions and findings included:

All corrective actions targeted affected rows or attempts and were implemented using targeted SQL updates, corrections via Qualifications or Registration/Enquiry screens, code fixes where reprocessing or audit changes were required, record merges for cross-account components, and accounting adjustments where invoice linkage or cancellations were necessary.

Supplied image and signature assets were added to each affected template and the templates were saved and published so newly generated documents used the updated images and text. In LetterWriter, revised JPEG assets were uploaded to the 'LIBF Walbrook Header/Footer' location; the CPACERT certificate image was replaced with the LIBF/Walbrook dual‑branding asset, a shorter footer was applied where requested, Mark’s signature graphic was replaced with John Somerville’s signature and the job title was updated. In DokGen the requester’s example and signature file were inserted into the 'Zertifikat Online‑Weiterbildung - DS' template so signatures appeared on generated certificates. In myLIBF the SPS and CPA certificate templates were updated: the top LIBF logo was replaced with the new Walbrook/LIBF branding (aligned with FCA register formatting) and the bottom certificate text was changed to the requester’s legal wording referencing Walbrook Institute London Limited and the Peninsular House address. The root cause in each case was traced to template assets rather than application code; availability and visibility of updated assets to the requester were confirmed. A separate large‑scale rebrand affecting roughly 275 templates plus JotForms, LiveChat/virtual assistant prompts, phone messages and DCWEB was investigated and found to be constrained by LetterWriter’s per‑template asset model and template versioning; universal automatic global updates were not possible, so rebranding work was handled as per‑template/manual updates with prioritisation across the affected systems.

Permission- and feature-related issues were resolved after confirming users had active product accounts and the expected product-level access; when group or space membership had just been approved access sometimes became available after the user retried, indicating provisioning/propagation latency. Personal-space problems were resolved when the Create Personal Space global permission or appropriate group membership was enabled and the Personal Space option reappeared. Space- and page-access issues were resolved by inspecting space membership and page‑level restriction lists and adding requesters to allowed editors/viewers, or by coordinating changes with the space owner; when space owners were inactive support transferred ownership or assigned IT teams as primary owners to restore administrative control. For sensitive pages whose owners were unavailable, pages were removed after colleagues confirmed credentials/secrets had been secured. Self-service access-request flows were used to grant general Confluence access while space membership still required owner approval. Missing dashboards and third‑party content were resolved after confirming whether content resided under a different domain/space. Intermittent or inconsistent UI controls were investigated by checking browser session state (cache/cookies) and testing in a private/incognito window. Trello Power‑Up activations were resolved by engaging workspace admins and vendors to complete the admin‑level enablement path so the Power‑Up became available workspace‑wide. Import/export and permanent‑deletion requests were completed after accepting archives and performing the operations, then granting the requester space‑admin rights on the resulting or imported space. When Confluence approval/request items were inaccessible support inspected the workflow state and found items that had already been approved, declined, or canceled by the requester; canceled requests no longer required approver action and approvers were not always notified. Tickets were closed without IT action when other space administrators had already applied the requested permissions.

Templates that matched the plain-text pattern were updated via the existing PL/SQL batch process against the lw_template/text_store (using the PACK_IFS2000NEW.comTextStoreClob interface). Templates that the script skipped were inspected and corrected manually: non-standard formatting (superscript characters) and inconsistent HTML entities were normalized in the template source, then the corrected template content was saved back to the database. Problematic templates were edited individually to ensure the new address appeared consistently in current template versions.

The specified unused queues in the recruiting@iu.org OTRS instance were deactivated to prevent accidental routing. 'Talent Acquisition' and 'Workday' were deactivated on 2023-05-02; 'BS Dozenten' and 'CS Dozenten/Tutoren' were deactivated on 2023-05-04, removing them from available routing options. Separately, during the OTRS→Jira migration a report noted that after forwarding to OTRS had been disabled and an automatic-reply directing users to the Jira contact form was added, users clicking the link encountered an inaccessible OTRS Service Portal page (portal page not visible and not discoverable via portal search); this access issue was logged for investigation alongside the queue deactivations.

The user's Inventory360 account was confirmed active and the user was instructed to open the portal root URL, sign in via Single Sign-On, and navigate to 'Meine Dokumente' (My Documents) → 'Zur Unterschrift' (to be signed) to locate and sign the document. The user accessed the portal this way and was able to sign the handover protocol.

The floating 'D' icon was identified as the Lenovo Display Control Center floating icon. The icon was hidden using the application's float-icon control, after which the overlay disappeared and the user confirmed the issue was resolved.

The DokGen configuration errors were corrected and verified. The mistyped date-rule was changed from 21.12.2022 to the intended 21.11.2022, and test documents were generated to confirm that certificates/diplomas dated 21.11.2022–20.12.2022 now carried the expected signatory. Separately, the rector-name rendering in DokGen was fixed so the certificate showed the correct left and right rector names (previously displayed as Prof. Dr. Peter Thuy; corrected to left Prof. Dr. Holger Sommerfeldt and right Prof. Dr. Tobias Brückmann), and a sample Zeugnis was produced to validate the fix.

Two root causes were identified and resolved. First, tickets closed beyond the archive threshold (~six months) had been moved to the OTRS archive and were excluded from normal search results; affected users were granted the archive-search attribute ('Archivsuche') in their search view/permissions and archive searches were run with the search scope set to “All Tickets.” Searches were optionally narrowed by owner/responsible and by date range to improve performance, and results were exported to Excel when required. Second, several OTRS queues had been deliberately disabled during input-channel migrations (Sf), which removed queue entries from users’ views and prevented access to historical threads; the disabled queues (including StudSek and PA) were re-enabled and read permissions for staff were restored, which returned the missing queues and made historical tickets findable via search.

Issues were resolved using a combination of configuration fixes, targeted backend data corrections, completion of missing assessment inputs, and selective removal of erroneous Invalid Results entries. QBEAM / DRDB v7: blank or incorrect QBEAM Papers configuration was removed or corrected (blank paper rows were deleted and affected papers were switched to Random where appropriate). Scoped Oracle SQL updates were applied to qbm_test_result (Original_Id corrected to the expected format 'S' + Registration_Id + '/1') and qbm_test_result_paper rows (including setting end_date on specific rows) limited to the affected paper_code/registrations. Where QBEAM rows represented spurious or duplicate entries (for example PETR contingency students), operators removed the specific result entries from the QBEAM Tests/Invalid Results folder. Validation-mismatch cases included SPF results missing required answers (Q54); completing the missing response allowed QBEAM to re-run checks and the results to commit. Pearson Invalid Results: at least one case was caused by a registration element not assigned to Pearson; restoring the registration element at source allowed the result to be pushed from Pearson’s Invalid Results UI (an authorised user performed the push when direct access was unavailable) and backend records were updated. A reported No‑Show (NS) existed in the Pearson IFS archive but was not attached to the student record; because Pearson could not re-send NS files, investigators applied targeted database record corrections together with QBEAM configuration fixes so the NS became attached and the result committed. Eligibility-sync timing issues that recorded bookings against registrations already closed were handled by restoring/opening the registration element where possible, pushing via Pearson Invalid Results when available, or applying precise backend corrections to attach deliveries to the correct registration.

Duplicate/missing semester entries: Resolved by repairing the student's plan/plan-calid data — duplicate calid rows were removed and missing calid rows were added or mapped so the semester dropdown displayed the correct sequential semesters and previously uploaded practice reports became accessible. Week/counter display: Investigated an off-by-one week-count shown at quarter start; support confirmed the discrepancy was cosmetic only, that Praxisberichte functionality was unaffected, and the issue was forwarded to the specialist team for awareness with no corrective action required.

Restored employer Deutschlandtickets using one of two methods depending on available information:

CONGRAT-related missing digital certificates were restored by reprocessing affected completion records with a special LetterWriter bulk run (CONGRAT template, CONGRAT5 bulk variant) from the Bulk Request screen; that reprocessed records were pushed to DCWeb, which restored certificate-number generation and visibility in MyLIBF. Intermittent QUALCERT bulk-job failures that appeared as 'Failed' in Bulk History were resolved by retrying the bulk (the retry completed successfully); recurring QUALCERT failures were remedied by restarting the Bulk Process service on server LWPS2022 (stop then start), which restored normal bulk processing. Instances where DCWeb showed no certificate despite the export or individual-record status reporting success (status = 0, error = null) were resolved by reprocessing the completion records through the LetterWriter bulk re-run, which restored DCWeb visibility. For FE certificate-data gaps, analysts queried student-records/FE certificate datasets for qualifications LIFA, LIFC, CFCD, AIFE, CEFE, TCF, CFS3 and DFS3 where grade was not 'U' and not 'F' and either Certificate Date or Certificate No was NULL; the resulting export of affected records was produced for downstream remediation and reprocessing to restore missing certificate metadata.

Duplicate and stale operations were resolved by removing or cancelling the later-created duplicates and by escalating queuing anomalies for specialist investigation. For the CMA approval duplicates, operators identified later duplicate rows in the sps_request table and executed a targeted DELETE removing duplicated unapproved/unrejected/unwithdrawn CMA requests for the same contact, restoring a single approval entry per candidate. For student registration duplicates created during transfers to BS, support staff identified duplicate module registrations (MRT1 and MRT2) and cancelled the duplicate registrations in the enrolment/registration system when UI cancellation was not possible; cancellation confirmations were communicated to the requester. For unexpected Twilio calls/tasks that ran after candidates had booked/completed an EEB, the incident was forwarded to the specialist team; investigation determined that the queuing/task-creation logic generated Twilio Tasks for applicants who had not immediately booked an EEB, which allowed those tasks to be executed later after an EEB was booked. The queues and task records were inspected and the findings were communicated to stakeholders.

Exemptions were added via the Registration Admin Exemption Codes screen. A new exemption code and description for "CFA IMC" were created and associated to the relevant subject codes; when a whole module was to be exempted, each subject within that module was added individually. Changes were saved and the exemption was applied.

Dispatch failures were resolved by addressing both accounting/registration blockers and a release-logic gap for free materials. Customer Services cleared outstanding ELCAS payments and corrected invalid CeMAP module registrations (notably MRT2 and UKFR) in the student records. Where stock or invoice records had been marked 'invalid' (often after credit notes or due to non-payment on closed registrations), those stock invoice statuses were manually set back to 'valid' so the textbook-release pipeline could pick them up; the dispatch process was then retriggered and items sent to fulfillment. Separately, a release-logic fix was deployed to prevent free additional books/materials from being released when the student's linked registration invoice remained unpaid; records were reviewed and the small number of students affected by the prior behaviour were corrected. Systems affected in these incidents included ELCAS, invoicing/stock invoices, the student registration system (UKFR), Carousel/Distribution, online payments, and the inventory/textbook release process.

PDF24 Toolbox cases were resolved by using the 'PDF unterschreiben' (Sign PDF) feature in PDF24 Toolbox: a signature was created by uploading an image or drawing it, the created signature was selected and placed into the document, and the resulting PDF contained the inserted signature. For Adobe/DocuSign/Acrobat cases, support resolved the issue by sending an Adobe Sign invitation to the user, which enabled the user to complete the e-signature workflow; the invitation typically arrived within about 30 minutes and restored signing functionality.

Support confirmed Microsoft 365 cloud storage had available capacity, but the failures persisted until local scratch usage and cloud sync of active temp files were addressed. The problem was resolved by freeing local scratch-disk space and preventing Microsoft 365 sync from holding Photoshop's active temp/preview files: Photoshop's scratch-disk was switched to a local drive, Photoshop caches and temporary files were cleared, and active working files were moved off or excluded from OneDrive/SharePoint sync. After these changes preview generation and save operations completed without the 'virtual memory / scratch disks are full' error.

GIF sending was restored after the Teams setting for 'Optional connected experiences' (under Privacy) was enabled, which re-enabled the GIF picker functionality.

Teams failures on affected OEM Windows laptops were resolved by applying device vendor system/driver/firmware/utility updates via the vendor’s updater utilities rather than relying solely on Windows Update. On Lenovo devices the issue was resolved by running Lenovo System Update, installing all reported firmware, driver and utility updates while the laptop was on AC power with the battery charged, and rebooting as required. On Dell devices the issue was resolved by running Dell SupportAssist (Complete Scan) and Dell Command Update, installing driver updates identified there (notably display/graphics drivers), and rebooting. After those OEM firmware/driver/utility updates were applied, Teams responsiveness, meeting behavior and recordings returned to normal and client startup/update‑error messages were cleared so the client could launch. Some incidents presented specifically as the new Teams desktop client having delayed camera activation (~10–12s) or screen‑sharing freezes while the web/old Teams remained functional; these symptoms were observed within the same set of OEM-managed devices affected by the other Teams slowness/startup issues.

The root cause was a trailing whitespace/paragraph character in the Curriculum module title. Removing the extra trailing whitespace/paragraph mark from the module title in the Curriculum module descriptions and regenerating the document removed the box glyph from the produced certificate.

The NS entries were approved by using the Registration Results application: the Registrations screen's Exam Flag dialog was opened and the dropdown control at the bottom was set to the appropriate approval value for the NS entry, then the change was saved/submitted. Once that value was applied the NS status was approved.

The investigation identified the root cause as per-line percentage discounts combined with line-item rounding: the discounted unit price (example £1,100 → £666.33 after discount) was not evenly divisible by the quantity of three, which produced 1–2p differences in totals. The invoice was corrected via intervention and the promotion parameters (discount percentage and validity) were recorded; no systemic rounding change was applied in the ticket.

It was confirmed that MyLIBF homepage behaviour was working as designed: the homepage displays only the most recent attempt for a unit, so if a resit is registered the resit attempt appears on the homepage. Prior attempts and their analysis sheets remained available through Study History and the Previous Analysis Sheet view.

Key‑all operations were executed to correct the grading impact of the misallocated items. For each affected item the team awarded one additional mark to students who had that item and answered it incorrectly, updated QBM responses and assessment result tables, and recalculated affected result_element/grade_band records so final grades reflected the adjustment. The changes were performed via targeted SQL/PLSQL updates against qbm_item_response and the Oracle assessment tables and verified against provided counts (including item 36585 and the three CITF items).

Source and application datasets were reconciled and cleaned: cancelled programs and malformed records were removed or replaced with canonical records, and corrupted teacher entries in Skillsmap were deleted and recreated by affected users. The RunPMSSync Azure Logic App was re-run and application credentials were refreshed from the 1Password employee vault so subsequent PMS syncs no longer reintroduced deleted items. Stale or incorrect PMS_Course rows and Kurs/Hierarchy/Modul/Studiengang/Contact relationships were corrected in the app database. Courses that had lost kurscodes and appeared as numeric-only entries were fixed in the Skillsmap and PMSKurscodes datasets and corresponding Power BI/Skillsmap dashboards were updated. file_path entries in PMS_Course that pointed to wrong-language module handbooks were updated to the correct English files for affected courses (examples: DLBCSM101, DLBCSM201, DLBDSMFC01). All obsolete kurscodes identified (for example LIBF and UFRED) were removed so incorrect IU lecturer assignments no longer appeared. The 'only upcoming courses' filter logic was changed to exclude courses flagged 'staffing not required' and affected Spanish‑language courses were removed from the view. A missing-kurscode issue reported for a lecturer was noted as potentially related to the staffing flag and remained under investigation. During triage a client-side Moodle/KLAUS plugin behaviour was recorded where retroactive assignments could overwrite or drop previous assignments (producing placeholder users and transferring quotas); this behaviour was logged for further investigation. Stakeholder data‑management requirements captured during triage included bulk course-start upload (Excel/CSV) with fields such as kurscode, kursstatus, versions-id, sprache and active/from; bulk corrector-assignment fields (korrektor/in, kursstatus, active/from, kontingent, reihenfolge and from/to date range with open-ended 'to'); and an audit trail/history logging timestamps and user for data adjustments. A missing employee record (Annika Nageldiek) was added to the OnCampus MA Bonus database in Power BI so the colleague appeared in the Bonus Dashboard. Separately, an IU Module import to Quercus (IUMODULE) was recorded as failing to pick up modules; a mismatched module start date was corrected and the import retried but the issue persisted and was logged for follow-up investigation. Additionally, missing courses in the Notenmeldungsystem were reported for BE II (SoSe2024) at Freiburg and Nürnberg; that report was closed as a duplicate and forwarded to the Fachabteilung, and no technical remediation for the grade-reporting system was documented in the tickets.

It was clarified that 'Qualification Completion' digital badges were lifetime awards and did not expire or require re‑application; the "(last 12 months)" text referred only to the back‑populate (historical award) filter that limited back‑dated awards to those completed within the prior 12 months. That clarification was recorded and communicated to badge administrators to remove ambiguity. Separately, a dashboard tile in the Upskilling app still showed the old German label "Zertifikatsdownload" after the wording had been changed elsewhere; developers replaced the tile text with the updated label "Zeugnisdownload" and deployed the change (implemented and confirmed 2025-08-14).

Issues were resolved by restoring or refreshing affected users’ authentication/session state, by local client restarts, or by vendor-side fixes. Observed concrete resolutions included: password resets to regain third-party access (for example Calendly); users signing out and signing back in which cleared workflows (verified using support impersonation); clearing browser cookies/cache or using a private/incognito window where sign-out/sign-in alone failed; full logout/login cycles that restored tokens/API-key access and made missing UI elements visible; and a local device reboot that restored a native feature (screen sharing to a C6 endpoint). A recurring Jamf Connect macOS password prompt stopped after the user opened the Connect menu and authenticated. Some defects required escalation to application owners or vendors; vendor-deployed fixes addressed a Twilio sidebar account/context mismatch while other Twilio presence/status defects were escalated when restarts and network checks did not help. One SSO login flow stalled for about 20 minutes while the user was on VPN and was triaged/escalated after re-login attempts failed. One upload failure matched an intended 15-minute auto-logout window. Repeated WhatsApp Business Web logouts were traced to absence of the verification phone/SIM. One portal displayed an unresponsive "weiter" (next) button and an input window that auto-closed after six hours; no permanent fix was applied during triage. In summary, fixes fell into user-side session restoration (password reset, sign-out/sign-in, cookie/cache clearing), device restart/reboot for native client state issues, confirmed intended timeout behavior, or vendor-side code fixes and escalations.

IT obtained the device serial number from the requester, retrieved/generated the appropriate 1Password recovery key for the device/account, and securely transmitted the recovery key to the requester's delegated contact. The provided recovery key allowed the user to unlock the computer and regain access.

Investigations found two distinct sources of persistent obsolete qualification content and both were cleaned. For Oasis/examiners: the session-creation screen used a shared template whose element list was copied into every new session and consumed by the examiners system; removing obsolete elements from that template stopped them appearing in subsequently created Oasis sessions and in examiner assignment lists, and teams were notified to confirm examiner/result mappings after template changes because the same template fed multiple systems. For IRI/content repository: support confirmed deletion of obsolete qualification codes and removed paragraphs/sections no longer used (examples: legacy CDCS/CDC2, DipFA/DIPF2, CITF/CIF2 and old/closed banking quals such as DipPP). Where qualification paragraphs did not appear in the Qualifications Paragraphs view, support performed manual removals in IRI to eliminate the hidden entries. The combined fixes removed legacy-format elements from session creation, examiner assignment screens, and the IRI content store.

The MEA onboarding form was corrected: the private-email field was made required and moved into the primary personal-details section, and Employee ID/telephone requirement flags were aligned with updated rules. The MEA request type was linked to standard onboarding sub-task templates so Okta/IU account import, Epos/Care/myCampus account, hardware order, and credential-dispatch sub-tasks were created automatically on submission. Jira Service Management forms were reviewed and republished; bilingual forms were separated and missing description texts restored so English and German variants no longer mixed. A new 'Standorttätigkeiten' category/subcategory was added for site-activity requests with requester-specified required fields and delivery-address behaviour clarified (CMDB selection vs free-text depending on workflow). An automation was implemented to create a comment/notification when custom/detailed due dates expired so assignees received timely notifications, and template links/automations were validated to ensure consistent automatic sub-task creation and due-date handling across the portal. Portal configuration items and labels were corrected where inaccurate (for example the portal item label "IT Security und Datenschutz" was renamed to "IT Security"). Approval and workflow issues were addressed in practice: a Calendly account request that was stuck in an 'is waiting for an approval' state was progressed by sending the Calendly invitation directly and by correcting the approver assignment on the request; approver assignments on affected requests were updated as needed to unblock fulfilment. The Self Service software catalogue was updated to include Amplitude; the existing Okta assignment group (IU-ZZ-OK-ASS-Amplitude) remained in place for post-approval provisioning and approver ownership for that catalogue item was reviewed during triage.

Confluence templates supplied sample pages only at the moment a space was created; switching a template later did not retroactively change or convert pages that were already created. For this issue the team created a new Confluence space from the chosen template and migrated the required pages from the source spaces into it. Pages were moved or copied between spaces using Confluence page-move/copy actions and permissions on the target space were updated as part of the migration. The template choice for the new space did not alter the structure or content of pages that were migrated — templates only affected the initial starter content of a newly created space. When reusing a SpaceKey/URL, uniqueness prevented creating a new space with the same key while the original space existed; reclaiming a key required removing or renaming the original space before a new space could use that key. Confluence is page- and space-oriented (wiki-style pages and hierarchies) rather than SharePoint’s file/library-centric model, so migration and permission considerations differed accordingly. Reference documentation for creating spaces from templates was used to validate the approach.

Reporting requests were compiled from the reporting system and delivered by email to the requesting business teams. For the SS22 quality KPI, the count of script orders (93,717) was compiled for the semester window and delivered to the Evaluation team at evaluationen@iu.org on 2022-10-10; the process was documented for repeat execution at future semester boundaries. For the payer pricing request, the current Payer account prices per product were compiled following the provided sample report and emailed to David Nieto (report sent by Ruth Sandford on 2025-12-09). Both tasks were completed as data extraction and delivery actions using the reporting system and standard email distribution.

Template, mapping and data-source defects in DokGen and related services were corrected, redeployed and/or escalated so regenerated documents reflected accurate wording, fields and formatting. Key remediation and outcomes included: • Fixed template-to-data mappings and study-program settings so FS GEP time-models no longer produced explicit 'ERROR' strings and affected templates (Zeugnis, Urkunde, Studienabschlussbescheinigung, Diploma Supplement) used consistent labels and wording. • Removed duplicated paragraph text (for example the English Studienabschlussbescheinigung first-paragraph duplication) and restored missing legend entries (for example 'A = Anerkannt' and 'B = Bestanden') across affected cohorts and modules. • Updated retrieval/query logic to exclude superseded failed exam attempts and eliminate duplicate module listings so transcripts no longer showed prior failed attempts after a later pass. • Corrected grade retrieval so Bachelor thesis grades printed whether stored as a single 'Bachelorarbeit' module or as individual course records; a grade-classification mapping defect with the vendor (Simovative) was logged and escalated to restore consistent textual grade categories. • Resolved ECTS and number localization: set the decimal separator to comma, suppressed unwanted decimals for integers, and printed ECTS totals only where appropriate. • Restored German study/time-model labels, corrected wording typos and footer contact fields, ensured German month names in date formatting, and changed date sourcing so certificates used the date-of-last-examination (Tag der letzten Prüfungsleistung / Prüfungsdatum) from the student booking field for FS/DS/MS/KS units rather than the Notenblatt date where requested. • Fixed name and degree rendering to include second given names, correctly printed degree abbreviations '(B.Sc.)' and '(M.Sc.)', and populated missing Qualification.Student Full Name values so DCWeb/Smart Verify and verification text rendered student names. • Updated the English Studienabschlussbescheinigung template to include birth date and birthplace fields. • Restored generation, download and printing functionality where reported, including resolving a specific MSD 'Imma' error that had produced error attachments and blank-page prints for Immatrikulationsbescheinigungen; the Immatrikulationsbescheinigung service was returned to online availability. • Replaced the old campus address with the current address ('Weseler Straße 480, 48163 Münster') in the address source and corrected site/location mapping that had caused missing or incorrect address blocks for some myStudium/MSD students. • Corrected SESSUR/Oasis overnight email template content so qualification names included usual abbreviations (example: 'Level 6 Diploma in Financial Advice (AdvDipFA)') to avoid ambiguous qualification text. • Applied a fix to the Transcript of Records (TOR - Duales Studium) output logic so the Praxispartner (practice partner) field populated for affected semesters and the 'befristeter Selbstzahler – 8. Semester' placeholder was removed. • Captured and forwarded Overview-of-Grades and other overall-grade/output defects to the specialist team and vendor; Simovative investigated and restored correct Overview of Grades generation. • Logged template-specific change requests (for example date-source change to Tag der letzten Prüfungsleistung, replacement of editable processor-name with a fixed signer, support-unit-specific signer/address rules, and variable download filename requests) and forwarded them to the specialist/template team. Additionally, on the Stage environment a separate incident was investigated where document downloads failed because templates on Stage were empty; Simovative was contacted to verify whether a database/template synchronization had been performed and stakeholders were asked to confirm environment sync status. That Stage incident was documented as investigated but no remediation steps were recorded in the ticket. All confirmed fixes were deployed and affected documents were regenerated and verified where recorded.

Three distinct root causes were identified and resolved. 1) Record Type ⇄ Type ⇄ Topic(Thema) mismatches in the portal UI: when existing Type/Topic values conflicted with a Record Type change (or when Type/Topic were empty/locked) the case form and closure/reply controls became uneditable. Repairs included correcting or populating the Type and Topic/Thema fields and, where necessary, changing the Record Type; support sometimes updated these fields on behalf of requesters when they could not edit them, and one incident required escalation to SalesTech for backend/permission correction. 2) Stuck work-item (WA)/task states: the 'End' button appeared disabled while an underlying WA/task remained assigned or stuck; removing or reassigning the stuck WA/task restored the End button and allowed status changes. 3) Reply-template defect for older tickets: when replying to tickets older than 24 hours the reply template could be sent but the reply text field would not accept additional input; development rebuilt and improved the template-reply feature and deployed fixes, after which template replies accepted additional text again. In all cases browser refresh or clearing cache/cookies did not reliably resolve the conditions.

An evaluation of options was completed focusing on collaborative vault solutions versus file-based tools. A managed service (1Password) was recommended/implemented for team-shared credentials to provide shared vaults, role-based access, licensing, invitation/provisioning workflows and cross-user synchronization; KeePassXC was retained as an option for isolated/local vaults but was not used for cross-team shared provisioning. Guidance on licensing and invitation provisioning was provided to the requesting team.

Investigations covered multiple distinct template, configuration and bulk-data causes across DokGen/EPOS/STARTA, DMSD, MyStudium, LiFE, LIBF and related selection UIs and apps. Key outcomes and actions included:

Where applicable, fixes involved updating template variants and mappings, correcting database-driven field logic and date calculations, adjusting whitelist/configuration values, restricting document visibility by cohort/product identifier, regenerating affected templates/documents, forcing pending publishes, removing erroneous bulk-run history entries, and verifying outcomes in staging or production. Investigations that uncovered program-specific generation or configuration gaps (for example EU-ODSP / OI-SP) were recorded and handed to the responsible teams for configuration alignment with the status-based issuance rules already applied in DMSD.

The PEOP board was reconfigured: the "Undefined" column was renamed to "Backlog" and mapped to the Backlog status; new columns and statuses were added (e.g. Pending WCC Evaluation -> Pending Evaluation; Completed WCC Evaluation -> Completed Evaluation); existing columns were remapped to the requested statuses (including Priorization Meeting -> Priorization Meeting status and Selected for Sprint -> To Do status); column order was enforced as requested and unchanged columns (Blocked, Cancelled, Done) were left intact. The separate Backlog view was deactivated where status was present on the board.

Technicians completed installs, updates, and availability requests either by interactive remote session (TeamViewer) or by packaging and publishing applications to the Company Portal/self‑service catalog and confirming availability. Interactive sessions were used to apply vendor installers when required so updates registered correctly (for example applying a Lenovo vendor updater), and macOS launch failures (including “app appears to be damaged”) were resolved by applying vendor updates or reinstalling the app remotely and restarting the application (for example Microsoft Teams; the Teams web client was used as a temporary workaround). Published Company Portal applications (for example Adobe Creative Cloud/Acrobat Pro, Citavi, VeraCrypt, Eraser) were confirmed available and reinstalled when needed to repair installs or restore file associations. For browser‑based vendor installers technicians supplied vendor download links, the company download password, and notes about required browser permissions. When elevated permissions were required technicians used non‑admin Company Portal deployment options where available or processed admin‑approval requests and recorded approver information. For cloud‑hosted SaaS technicians confirmed whether a local component existed, escalated to the cloud/specialist team when necessary, scheduled update windows, and had specialists perform instance updates and verify availability. For vendor security notifications technicians verified notices against Security‑Portal data, sampled endpoints to determine scope, pilot‑tested vendor updates, prepared packages or patches, deployed them via the appropriate publishing channel, and recorded actions in session notes, portal entries, or intranet announcements. GDPR‑relevant packaging decisions were recorded (for example packaging and publishing VeraCrypt while recommending Eraser for secure deletion after noting some apps created backups outside encrypted containers). For small peripheral utilities (for example SharpKeys on Windows 11 which modifies the Scancode Map and required .NET 4.0 Client Profile) technicians obtained and recorded any required approval under the private‑hardware/peripherals policy, installed approved utilities from vendor sources, applied requested remaps or configuration changes, and documented approvals and registry changes. Requests for free or open‑source software (for example Inkscape) were handled like other catalog items: separate requests were processed per distinct title, and technicians either packaged and published the app to the Company Portal or supplied vendor download/install guidance when portal publication was not feasible. For Windows Store–only apps (for example BrainVoyager Brain Tutor) technicians confirmed store availability, evaluated Microsoft Store deployment versus alternative packaging options, and either listed the app in the corporate catalog or provided installation/procurement guidance. When requesters found the formal Software Request form burdensome, technicians accepted standard portal/Jira requests for low‑cost or free software to reduce friction while recording approvals and processing details.

Reference-data mismatches and stale eligibility records were corrected and impacted submissions were re-sent. Specifically: the missing phone country-code for East Timor was added to the internal student/CRM reference data and the candidate record was updated and re-submitted to Pearson VUE, after which demographic validation completed. Country-name mismatches (for example differences between "Vietnam" and "Viet Nam" in PCA Predict/Area_Code_OS and the registration list) were resolved by standardizing stored country values so the registration portal accepted selections. Generic Pearson VUE eligibility uploads that failed with processing errors were cleared by forcing manual re-submits; the re-submitted eligibility records were picked up and registrations appeared in RegMAN. In cases where internal registration lifecycle changes (transfers, cancellations, re-additions) or incorrect cancel reasons left obsolete modules visible on Pearson VUE pre‑approved exam lists, the registration records and cancel‑reason values were corrected and stale eligibilities were removed or regenerated so Pearson VUE no longer presented the old modules; after the corrected eligibility state propagated, affected OnVUE system checks (previously failing with "the programme is already running") ceased to block candidate check‑in. It was also observed that certain field edits (for example changing a phone number) could trigger a resend of contact/eligibility data in the integration, which was used to refresh downstream systems when required.

Developer implemented a UI change that added a toggle button which switches between rust and black. The new "T" toggle (rust) button was added next to the colour picker so the rust colour (RGB 222,77,10) could be applied without re-adding it; the change was pending deployment at the time of the ticket.

The affected page's link target settings were changed so links opened in a new tab/window (external target) instead of inside the VLE reader. Links were tested to confirm direct navigation to the external database and access to EPUB/PDF and full database features. Content owners were notified and the Apprenticeship Programmes team was reminded to set link targets to open externally.

The failures were traced to an interaction between the installed K-Lite Mega Codec Pack (KLCP_K-LiteMegaCodecPack_19.0.1) and the graphics/GPU driver on Windows (reported on Dell laptops). Replacing or reinstalling the codec pack did not resolve the symptoms. Remote troubleshooting used EPM/TeamViewer to inspect driver state and the issue was resolved by reverting the GPU/graphics driver to a previous known-good version via Device Manager. Docking-station testing and other environment checks were performed during troubleshooting but did not change the outcome.

Two distinct causes were observed and fixed. 1) Local client state: recurring Jamf authentication dialogs were cleared by reconnecting Jamf (initiating a Jamf Connect reconnect from the macOS menu bar removed persistent authentication popups). 2) Backend/service incidents or transient Keychain-related failures: Jamf Connect stopped connecting and Self Service / Self Service+ presented “password not matching” errors or a continuously reopening macOS Keychain modal that blocked admin requests and password sync; Okta password-change attempts could fail with insufficient-permission errors during these incidents. Those cases were resolved when the JAMF/service-side systems recovered (some tickets reported the issue self-healed) and did not require user-side configuration changes.

A two-part resolution addressed the incidents. First, a developer fix resolved the blank-detail/display and grade-editing failures; the fix passed Stage testing and was promoted to Production, which was updated to version 17.14.12, after which individual exam details displayed correctly and grade-editing functionality was restored. Second, root-cause investigation into visibility and count mismatches established that the Corrector Overview was subject to assignment/tutor-based filtering (a visible "tutor" column) that caused different counts between the general grading list and the Corrector Overview and prevented non-assigned graders from opening or seeing some exams; the investigation findings were recorded and passed to the grading-UI/assignment-logic owners for reconciliation of assignment-based visibility with expected grader access. Operational notes: affected users had been advised to try client-side troubleshooting (clear cache/cookies, different browsers, incognito, different workstation), but these steps did not resolve the problem and tickets were escalated to the specialist team and the Examinations Office as appropriate. A referenced error screenshot was not available in the record.

Microphone-direction failures were resolved when a full shutdown and restart of the laptop restored microphone audio. Support also recorded that using the headset’s supplied USB dongle acted as a reliable workaround for Bluetooth audio issues in Twilio. Clearing the browser cache was suggested as an alternative troubleshooting step. For reported speaker/output-direction failures there was no confirmed resolution in the ticketed case; support had suggested identifying the headset model and connection method (USB, 3.5mm, Bluetooth), confirming that other applications (for example Microsoft Teams or YouTube) produced system audio, ensuring Google Chrome was used (or testing an alternate browser), clearing the browser cache, and signing out of and back into Twilio, but those actions were not verified as resolving that incident.

A repeated factory-reset sequence via macOS 'Transfer or Reset' was used: the existing profile was deleted, the machine was allowed to restart, then powered down and hard-started; repeating this sequence ultimately restored the Self Service (IU Group) presence and enabled VPN/remote administration access.

Support clarified ownership and then either applied requested changes directly or routed requesters to the appropriate owner. For IU public website CMS content owned by the web team, support applied updates and scheduled deployments when required (examples: added supplied photos, emails, and homepage links to IU profiles; updated Trade Registry / myLIBF CMS text to replace “QTFS” / “Diploma for Qualified Trade Finance Specialists” with “QTFE” / “Diploma for Qualified Trade Finance Experts”; coordinated deployments with student-honours updates). When Meldeportal form fields or options were owned by other project teams, support routed requesters to those owners, who implemented the requested changes (example: added “Copilot” to the KAM form’s “Valid for the Units” field). For content owned by other portals (for example the IU career portal), requesters were directed to that portal’s service desk. When intranet navigation labels were inconsistent with page content, support updated SharePoint navigation/menu entries (example: renamed the menu entry under “Hochschulbereiche” from “Academic Administration” to “Academic Operations & Strategy”) and notified requesters. When intranet pages were unpublished or needed placement, a specialist published the page in the requested area and verified permissions and access settings (example: published a team intranet page under “Hochschulbereiche” next to “IU Rekorat”). In cases where agents could not take action or transfer ownership, support advised requesters to submit changes via the appropriate Meldeportal form and closed the ticket as “won’t do.”

The user was enrolled in the 'Copilot for M365 Essentials' course in the IU Learning Hub. After the course status was recorded as 'completed' the Copilot for M365 license was assigned automatically and Copilot features became available within the stated propagation window (up to 72 hours).

Investigations reproduced multiple cases where public-facing pages, intranet areas or service‑portal links pointed to incorrect targets, restricted views, renamed or legacy pages, or non‑secure/public forms. Resolutions and outcomes included: corrected misdirected registration links and amended misregistered Pearson VUE candidate records so candidate sign‑in succeeded; processed applications submitted via public forms through the secure application/payment pathway and reconciled missing payments (for example a referenced £57) against internal records. A filtered query of registration records (28 Apr–22 May, excluding resits) identified 65 affected registrants and an export/list was produced for follow‑up. Site content and navigation faults were reproduced and escalated where appropriate — for example a MyLIBF→Financial World redirect loop was escalated to the web/content team; an absent “Register” button on a corporate‑processed qualification was confirmed as an intentional content change and the requester was informed; mislinked external IU pages were identified as externally owned and requesters were referred accordingly. Intranet updates included renaming and publishing areas (for example renaming the old IUG Inside area to IUGTalentspace and publishing the new IUGInside area), adjusting permissions after the change, and notifying content owners to update navigation. Portal‑specific faults included users landing on limited catalogue views; one Service Portal case was resolved after verifying the user’s authorisations and providing the correct portal link, after which the user could access expected request types. Internal portal tile/link faults and pages lacking contact details were forwarded to subject‑matter teams and requesters were provided direct contact emails. Content‑level wording errors were corrected where appropriate: the CMP2 (CeMAP Module 2) registration text was amended to clarify regional applicability (England/Wales/Scotland) and a screenshot/preview was provided to the stakeholder for confirmation prior to publishing. Where applicable public links and backend registration records were corrected and payments reconciled; issues outside internal ownership were escalated or referred to responsible teams. Separately, a MyLIBF “Add Your Resit” button that opened an ordering/study‑material screen instead of the resit registration flow was reproduced; investigation checked application logs (no evidence the user visited the online registration site) and confirmed the code that generated links to online registration had not changed, but a definitive root cause was not identified. The affected student was registered manually by phone as an immediate workaround.

Issues were resolved by granting temporary administrator privileges so the required app install or privacy permission change could be performed. For Logitech MX-series devices, temporary admin elevation via SelfService+ was used to install the Logi Options+ application; after installation the Logi Options+ app was used to adjust DPI and device-specific settings. For Microsoft Teams screen sharing on macOS, the user was added to the Mac-ShortTermAdmin group to obtain temporary admin rights and macOS Sharing/Privacy settings were updated to enable Screen Recording/Screen Sharing for Teams; screen sharing then worked as expected.

An IU Group admin completed the workspace transfer of the 'shadcn/ui' kit into the Syntea Learn+ workspace. The design system was then available for the requester to add to files in the target workspace.

Support reproduced the bug, applied a manual account change to set the student as opted out, and a code fix was deployed to address the preference persistence issue. The fix was deployed on 2026-01-14 so the opt-out setting no longer reverted.

The request for a Zoom booking/calendar add‑on was declined by the automated approver routing (approver was unavailable, causing an automatic decline). Support recommended using Microsoft Teams instead because Teams provides equivalent scheduling functionality and Zoom is being phased out in the organisation. The ticket was closed after the automated decline and recommendation.

IT engaged the specialist team which identified and implemented a fix; the fix was rolled out to affected users on 2025-10-22 and the user confirmed the Think‑Cell add‑in was working again on 2025-10-27.

Investigation traced the printed invoice description to the Product Codes screen in Finance Admin. The system used the Product Codes 'External Description' when populated and fell back to the 'Description' field otherwise. The issue was resolved by updating the appropriate Product Codes fields in Finance Admin so the printed invoice text matched the expected value.

Investigation confirmed that MIFS renewal notices are generated 21 days before the record's end‑of‑term. For records with an end‑of‑term of 31 July, the system picked them up on 10 July. The user was advised to check the stopped emails on that date to verify the updated fee and release the notices; no system fault was found.

Investigations found multiple causes for silent or missing notifications and were resolved case-by-case. For the ITR reports, the scheduled ITR job had executed in the early hours and its output file contained rows for that run; mail logs showed the notification email was sent and at least one recipient received it — the issue was an expectation mismatch because the ITR job ran weekly rather than daily, and the run schedule and successful execution were communicated to the users. For the CPSP expiry reminders, the TIMELEFT setting for the CPSP programme had not been configured, so automated 6‑month and 3‑month expiry reminder emails were not enabled; TIMELEFT was configured/activated for CPSP, the reminder process was verified as running, and it was noted that missed reminders prior to activation were not sent retroactively. For CPA certificate notifications, there was no dedicated report to drive notifications; a new scheduled report (CPACERTD) was created and scheduled to run daily to provide regular CPA certificate send‑out notifications to the feexams team. In each case investigators verified scheduled runs, reporting output presence, and mail/log evidence of sends, and then communicated the status and any schedule/configuration changes to recipients.

Multiple incidents of missing or misrendered UI controls were resolved or triaged after targeted frontend, backend, and vendor investigations. Key outcomes and triage conclusions included: a developer deployed a bug fix to the CITR CPD logs UI so activity input fields rendered correctly and CPD entries could be entered and uploaded without the generic upload error; a MyLIBF CPD backend processing incident was investigated and cleared after support confirmed an Opayo payment and removed a processing block that had been triggered by an unusually large logged-hours value (~1,400 hours), and an administrator retried and completed a manual CPD entry; a Simovative Antragsverwaltung DS-Antrag workflow was restored after the vendor applied a backend/configuration change that returned location-based fields (Standorte and location-specific email controls); the thesis-title control for “Antrag 'Abschlussarbeit anmelden'” was replaced (Input -> Textarea) to remove the 150-character limitation (change implemented by Jasmin Eick) and the internal thesis overview view was switched to one exposing Unit filters and the multi-select thesis-status control, restoring expected filtering behavior. Separately, a PowerApps LCC billing form had its Submit (Einreichen) button disabled because the required “Modul-/Kursname” field could not be populated for certain CS master-thesis cases; that symptom and an associated Jira/IU password login failure were triaged to the PowerApps/LCC and authentication/Jira teams for follow-up. A MyCPD report recorded a student who could not log new CPD activities and received an error/notification instead of a completion confirmation; that ticket noted prior MyLIBF login issues and an Outlook auto-reply banner but no resolution was recorded. A D.velop report showed the “assign for editing” person icon was missing (preventing assignment actions); support escalated the issue to the specialist team but no technical fix was recorded and the ticket was later closed during stale-ticket cleanup with instruction to reopen if still relevant. New: a Freelancer Invoicing App user could not open or populate work-time entry fields (no additional input appeared and no error was shown); support captured diagnostic suggestions (app/version/field-visibility/permissions information) and forwarded the report to the application owner/development team for investigation, and the ticket was canceled pending developer response. Where fixes were implemented, they were the result of targeted UI bug fixes or vendor/backend configuration changes; several incidents required escalation to product/ specialist teams and awaited developer/vendor resolution.

Investigations separated two related issues. For missing purchase options, availability was driven by the student’s course registration variant: students registered only for the Scottish Mortgages variant did not see UK/English specimen papers. For ordering and payment problems, investigators found the registration/checkout UI allowed mutually exclusive options (bundles and their individual papers) to be selected concurrently, producing duplicate or incorrect orders. The checkout/payment-allocation flow then routed payments to the full bundle ledger even when only a single specimen had been purchased (examples observed: payment for learning-support code MCMSA11, £25, was allocated to bundle K59390). That misallocation prevented automatic entitlement; access was delayed until finance manually journaled funds to the correct ledger. Similar behaviour was reported for CRT partial purchases being charged to the full CRT bundle. No explicit error codes were produced. The findings were recorded and the issue was escalated for remediation; no production fix had been applied at the time of reporting.

Support confirmed the server connection was healthy and resolved the issue by reinstalling the local admin application. After the reinstall the ADMN1061-related UI errors ceased and normal interaction was restored.

The CPACERT LW template was found to have been 'ended' (auto-deactivated after a period of inactivity). The template was reactivated/restored to make CPACERT available again for the print job, after which certificate printing resumed. Notes indicated templates may be auto-ended after approximately six months of non-use and might need review if out of date.

Investigators confirmed the RETURN1 template's behaviour: it sets the ADDR suspend code on the roles record rather than deleting or removing the address. Guidance provided (and recorded in the ticket) indicated addresses must be removed via the Returned Correspondence screen, which also includes the option to send the RETURN1 letter if required.

Investigators confirmed the Jotform enterprise custom domain had migrated from forms.libf.ac.uk to forms.walbrook.ac.uk and reproduced the certificate and embed failures. Resolution actions included updating embedded form and asset URLs to the new domain and applying server-side redirects (via Cloudflare) from the old domain to the new to restore access to embedded surveys and images.

Incidents were triaged to confirm administrative ownership and then documented and routed to the owning team, business unit or external vendor when central IT lacked control. Support recorded detailed symptoms, ownership contacts and any attached logs or user report files, and redirected or escalated tickets to the appropriate product owner, exam office or vendor. When central IT retained administrative access, targeted fixes were applied and recorded: examples included replacing or re‑imaging a client PC to resolve an e‑test/admin console error, clearing browser cookies or switching browsers which correlated with resolution of recurring Turnitin XML plugin messages, and requesting server logs or a Sitting.zip when clients stalled at “Please Wait.” Reinstalling admin consoles sometimes failed to resolve symptoms. Short vendor outages and intermittent service interruptions sometimes self‑restored and were logged as restorations; persistent or systemic faults were escalated to vendors or product teams. Time‑sensitive submissions were logged and temporary alternatives (email, offline annotation and re‑upload, postal submission) were used while owners restored service; for inline‑annotation crashes staff downloaded submissions, annotated offline and re‑uploaded corrected files when immediate marking was required. Specific patterns captured in recent tickets were added to case records: proctoring servers returned authorization errors that prevented appointment selection or deregistration and a locked student laptop prevented Irium webcam installation due to admin‑installation restrictions; Twilio cases exhibited blank/black UI windows, extreme startup delays and mid‑call crashes requiring vendor engagement; a Kaltura request could not be forwarded because the product owner had left and no successor was available (ticket closed as “won't do” after user acceptance); Bongo and other exam tools were consistently referred to the exam office or product owners when central IT had no permissions; and duplicate user accounts in the exam/correction system caused missing correction entries and incomplete email notifications affecting billing. All troubleshooting actions, ownership confirmations, suggested temporary workarounds, recommended contacts and any vendor escalations were recorded in tickets. Incidents were closed after owners or vendors confirmed restoration, after users accepted documented alternative processes, or when no owner existed and the user accepted the closure.

The SharePoint administrator collected the page and external‑site URLs, added the external microsite to the tenant's allowed/secure sites list for embedding, and asked the user to retry. The embed subsequently proceeded without further action from IT.

Okta/SSO logins and seat assignments were verified and full product licenses were granted where required, but root causes were frequently at the group/team/document level rather than the individual license. Several Figma incidents were traced to group-level Enterprise restrictions that limited workspace creation to the Group owner or owner administrators; owner-level admins either created the requested workspaces or performed owner-only actions, and in one case IT provisioned a Figma account and instructed the user to sign in via SSO. In Miro, org- and group-level controls (team permissions, group roles, template visibility, and the user’s active team) prevented board/space/template creation or publishing even when users had licenses; incidents were resolved by switching the user’s active Miro team to one that permitted creation, by company admins creating the requested team on the user’s behalf, by changing template visibility to public and sharing it, or by updating group roles/permissions to grant create-space/create-board rights. In Lucidchart, IT had unlocked/assigned the application license but access to a specific document remained denied until the document owner granted permission; IT advised a short propagation interval (~5–10 minutes) after license assignment and clarified that file-level permissions were controlled by the document owner. These incidents were resolved via owner- or admin-level actions, account provisioning and SSO enablement, role/permission changes, or allowance for license-propagation — not by changing users’ individual seat entitlements alone.

SPS Import Bulk: The SPS Import Bulk commit failure with uploaded .xlsx files was replicated on the test system. An updated Import Bulk UI that addressed the detected incompatibility was developed and deployed to the live system over a weekend. After deployment, users retried imports and the update resolved the xlsx commit failures that had been caused by the prior screen's compatibility problem. Klausuren Tool (.docx): Separately, the Klausuren (exam) upload tool intermittently rejected valid .docx files with the error "the uploaded file is not a docx file and only docx files are accepted." The behaviour was observed across multiple browsers and on a private Windows desktop; a screenshot and the original .docx sample (DS_Klausurvorlage.docx) were attached for investigation. No technical fix was applied in the recorded ticket and the intermittent .docx recognition failures remained unresolved in that entry. The two issues affected different systems and were handled independently: the Import Bulk UI update resolved the SPS/xlsx failures but did not apply to the Klausuren upload tool.

The missing shipment file was identified on the sender side and was re-sent the next morning alongside the regular file set. Receipt was confirmed by Carousel, resolving the missing‑data issue which had originated on the recipient's server the previous night.

An internal approver confirmed there was no objection to uploading and using the IU institutional PowerPoint template in a private/personal Canva account, and the user was permitted to proceed. A separate institutional-access request was fulfilled by sending an invitation to provision IU Canva access so staff could create teams and collaboratively work with applicants; the request was completed and the ticket closed.

The resit registration option was disabled and the RRIB qualification record was closed in the system so that resits were no longer available. A verification check confirmed the qualification was closed and the resit registration route was no longer present in MyLIBF.

The NF3693 month‑end FE student numbers report was investigated with business owners who confirmed the FE student figures were legitimately zero; the NF3693 scheduled job and its distribution/sharing were disabled and the requester was notified that the report had been stopped. Separately, a ticket flagged that quarterly/monthly statistics (Oasis, Papers Report, Pearson, Brightspace and the reporting system) showed DNS = 0 for all qualifications and that fields such as Entered, Sat, Passed, Failed and Actual Students were ambiguous or mismatched. That issue was logged with data/reporting owners and the data mappings and field definitions were escalated for investigation to reconcile source systems and reporting definitions (no resolution recorded in the ticket).

The requests were forwarded to the OTRS specialist team. A specialist restored or corrected the user's access to the requested AgentStatistics reports and supplied direct AgentStatistics links for re‑running the reports (StatID 868 and StatID 879). For a separate reporting request that required counts broken down by service categories and selectable time ranges, the specialist provided an existing statistics view (StatID 905) and the user confirmed the view met the requirement. The specialist was unable to locate any additional report for ticket processing time.

Multiple web-access outages affecting iubh/iu/libf services were resolved through targeted interventions and varied root causes. OTRS web access timeouts were resolved by reinstalling the OTRS connector; after the connector reinstall, web access was restored and timeout errors ceased. A separate OTRS 5 performance problem (ticket open times around one minute) was traced to the product having reached end-of-service-life and to a recent hosting change that moved the service to a less powerful virtual machine and introduced an application proxy; those factors degraded responsiveness. The iubh-onlineexams Moodle 'Publish grades' report returned Cloudflare Error 524 and exhibited intermittent loads; that incident was attributed to suspected backend overload (background tasks, database or application load stressing web-server resources), but no documented remediation was recorded. A Service Portal/billing outage that prevented ticket submission and invoice payment was resolved when the provider restored the portal and re-enabled the affected user account. A separate institutional website outage affecting LIBF and IU sites in Germany and the UK was rapidly resolved by the MarTech specialist team, which restored the affected sites; no further technical remediation details were recorded. Several incidents lacked detailed post-incident remediation records.

Media Production recommended ScreenPal (formerly Screencast-O-Matic) as the primary solution for basic trimming/cutting of Zoom recordings and for automated subtitle generation; IU users accessed ScreenPal through the campus download URL (https://screenpal.com/iu-fernstudium) and authenticated via MyCampus (IU password). Snagit (approved for IU use) and Wondershare UniConverter were offered as alternative tools for subtitle editing. ScreenPal documentation/course materials and the media-production contact (cfe-video@iu.org) were provided to requesters, and at least one user tested ScreenPal and confirmed it met their needs. Separately, support encountered WebVTT (.vtt) files that would not import into Adobe Premiere Pro, showing either a 'File format not supported' error or an import dialog that stayed stuck on 'loading'. In at least one tracked case a user requested conversion from VTT to SRT but declined AI/cloud conversion due to privacy concerns; support did not perform the conversion and the ticket was closed without conversion steps or remediation being provided.

The supplied recordings were processed with noise-reduction and low-frequency rumble removal. Processed files were exported and replaced in the original location; the audio clarity improved markedly and an additional noise-reduction pass was planned. Work was performed and the ticket was marked done.

The initiative was not pursued because the exam format remained unchanged. The request was closed as "Won't Do" on 2024-11-04 and no Testothek was created or implemented.

Investigations identified three distinct root causes and corresponding operational outcomes. 1) Enrollment-step hard stop: records where the portal blocked progression to Enrollment (Step 3) were resolved after previously missing mandatory fields (notably Step 2.1 'school graduation') were completed and the Salesforce/SuccessFactors applicant status was corrected from a contract-like state; following those data/status corrections the insurance-number fields became editable and applicants could continue. 2) Portal <> Salesforce/SuccessFactors sync mismatches: when a new Opportunity Archive record was created or set as Primary in SuccessFactors/Salesforce the public portal sometimes presented a stale view (asked for already-uploaded documents or did not expose newly selectable program/company options); IT diagnosed these as synchronization/state-mismatch issues between SuccessFactors/Salesforce and the portal and documented that fixing the Opportunity Archive/primary-record alignment restored the correct portal state. 3) IU website / OBW UI defects and access limitations: several UI/flow defects on the IU homepage/OBW (examples included greyed-out or unclickable form fields across MS/DS/FS modules, a failing 'Interesse melden' button, and non‑binding flows forcing payment details) were determined to be outside the supported scope of the IT intake team; in cases where support could not access the Bewerberportal internally, affected users were redirected to the DS applicant-portal / careerpartner service desk or advised to file reports in the IU Meldeportal / Jira Service Management for the IU web application owners. Recorded support actions therefore included verifying applicant records and Opportunity Archive primary settings in Salesforce/SuccessFactors, applying missing mandatory data or status corrections to restore portal flow, and routing UI/synchronization/OBW defects to the appropriate web-app owner/service-desk (including providing the external applicant-portal/service-desk link when internal access was unavailable).

Support reviewed ticket histories and confirmed the tickets had been closed manually. They also clarified that OTRS uses the 'OTRS-ADMIN' account when a ticket is processed by an automation/rule or when a ticket had no assigned owner/responsible set. In this instance the owner/responsible field was not changed, which produced the 'OTRS-ADMIN' attribution. The investigation and explanation were communicated to the reporter, which resolved the confusion.

The account quota for CleverReach account 97334 was increased by 50,000 recipients. The change was applied on 2023-08-23 (handled by Sandra Stoll) and the requester was informed; no further action was required.

The deleted MarTech Confluence space was restored in the Atlassian Cloud. The restoration was completed and confirmed on 2024-10-30 at 12:16 by Dominic Utz, and the space and its content were made available again.

The embedding request was reviewed and evaluated. The decision was recorded not to onboard an organisation-wide Excel-embedding plugin because the capability was classified as a 'good-to-have' rather than essential for daily operations. The outcome was documented as Done and a narrower-scope approach (for personal or team-level use) was suggested for further discussion rather than enterprise licensing.

Deactivated-account invite failures were resolved by reactivating/enabling the affected Miro user accounts in the Miro administration; after reactivation the users were successfully added to the board. In a separate incident where a user lost editing rights after a surname change, the support team reviewed the user’s Miro permissions and documented that permissions were inspected; the ticket contains no further detailed remediation steps.

The issue was investigated and identified as a UI bug on the confirmation page that prevented keyboard confirmation when the filtered country list contained only one item. A fix was applied to the confirmation-page selection behaviour to allow keyboard selection of a single matched country while retaining PCA Predict for address/country autocomplete. Temporary workarounds were documented for users until the fix was deployed.

SharePoint news: The specific news article was manually added to the intranet home page so it became visible. The SharePoint news setup was then reconfigured with expert guidance so items published in the Cyber Security Services SharePoint space were automatically posted to the intranet news feed, and the automatic-posting configuration was verified after the change.

Twill events: Two recurring event series that were partially missing on the public homepage became visible after the Twill-to-homepage publication/synchronisation completed; the missing entries appeared after the propagation delay and visibility was verified.

The problem was reproduced and diagnosed as a performance issue in the students listing and CSV generation for large cohorts. Optimisations were implemented in the students listing and CSV generation process, the fix was deployed, and successful student listing and CSV downloads were verified for the previously failing cohort size.

The identified bulk jobs were removed from the overnight/bulk run so the listed letters no longer printed. The MIFSWELC bulk was ended to stop its overnight processing while associated email templates were left active; behaviour for MIFS records without Direct Debit (which receive the MIFSWE template) was confirmed as part of the change.

The problem was cleared after the missing authorization record was reintroduced on Pearson's side. The originally generated EAD file was re-sent and Pearson confirmed ingestion/creation of the hosted authorization so that subsequent update records matched an existing authorization. Once Pearson processed the create authorization, the update applied successfully and the registration was removed from the error report. The incident was attributed to a transient or ingestion failure on the Pearson side rather than corrupt local data.

The inability to create PDFs from Word was resolved by installing PDF24 (a free PDF creation tool) from the Company Portal as an immediate workaround; this restored the user's ability to export/create PDFs from Word. An Adobe Acrobat license request was also recorded and the Acrobat procurement link was provided so the user could obtain a licensed Adobe solution if required.

Requests were completed after the required approver approved the request through the IT Service Portal / Automation-for-Jira and any missing target details were clarified. In the Teams/Kanban case, once the requester specified the correct Team and the app admin actioned the Automation-for-Jira approval, the Kanban Task Board update/install proceeded and Planner/Kanban integrations resumed. In the Mentimeter case, the resolution noted that approvers must be a team lead or cost-center owner and that the approver approved the request via the IT Service Portal; lack of approver action led to the request remaining inactive and then automatically closing after 14 days. Requesters had the request completed when the designated approver took the portal-based approval action and the approval record was processed by Automation-for-Jira.

Support verified the recording was not yet published (recordings for Minerva sessions were typically posted the following day), monitored the platform, and confirmed availability once the recording was posted. The user was informed after the recording became available (recording posted on 2025-02-28) and access was confirmed.

Repeated spurious web-chat notifications were suppressed in the UI by using the "Clear issue" control while support captured Task SID and Conversation SID for investigation; agents were also advised to properly end conversations so tasks/conversations would not continue generating notifications. Separate WhatsApp delivery and visibility failures were traced to bugs in the Channel Switch: one bug caused messages sent via the switch to sometimes not be delivered, and another was specifically related to variable insertion/character-handling in message text that caused the first sent message to be invisible or unsendable. Engineering fixed the Channel Switch bugs and a patch/deployment was applied to Channel Switch (impacting Twilio/WhatsApp flows from portal and intranet sources). After the deployment, affected users retested and confirmed that both the repeated-notification UI symptom and the message-delivery/visibility failures were resolved.

Support closed the WhatsApp chat on behalf of the agent and the ticket was marked done. No detailed troubleshooting steps or root-cause documentation were recorded in the ticket.

Support investigated the %USERNAME% environment value and determined Windows was returning a shortened/legacy username when the original account name exceeded length limits. Access was restored by signing in with the full email address or by using the shorter Windows account name; those workarounds allowed the desktop app to authenticate successfully.

Support confirmed that assignment of a virtual room and provision of host key/meeting link details were managed centrally by the course-management team rather than by individual instructors or an automatic per-event UI. Instructors were directed to course-management/instructor guidance; course management normally assigned a virtual room for the course and supplied the host key or meeting link plus any occupancy/availability information for instructors to share with students. It was identified that MOSES/Mathplan did not include a “Durchführungsart” (execution-type) attribute to distinguish Präsenz, online synchronous, and online asynchronous events. That omission prevented scheduling automation from applying execution-type-specific default room/resource criteria (for example, allocating finite virtual rooms only for synchronous sessions and no room for asynchronous activities) and prevented generation of execution-type-based statistics/reports analogous to the existing Lehrquote. An enhancement request and requirements were forwarded to the business/subject-matter owners and the external vendor for clarification and specification; until the system change was specified and implemented, course management continued to manage virtual-room assignments and reporting workarounds manually. Additionally, a support ticket recorded that a user could not locate the MOSES planning tool or where to enter availabilities and that the Atlassian Assist virtual agent repeatedly requested clarification without resolving the request; the ticket recorded the sequence and was closed with resolution “Won’t Do,” and no additional documentation or technical fix was produced in that case.

Incidents were resolved by restoring or enabling the appropriate site- or workflow-level permissions and by addressing tenant-level sharing settings. For embedded Care-profile URLs and linked student resources, administrators updated SharePoint permissions so affected users could open the referenced URLs. For intranet document-list issues, site editing rights were enabled on the CX site and users recreated document lists modeled on the research team’s list. For Sitefusion cases where scripts could not be opened for editing, support engaged portal/system specialists and corrected workflow or script-edit permissions so the documents opened editable rather than read-only (tickets were sometimes reassigned to the portal specialist for follow-up). Where users could not share or manage access while signed in from another tenant, specialists or tenant administrators adjusted external-sharing or tenant-permission settings after support captured the site name and link and escalated the issue. Microsoft Teams was used to coordinate and assist during changes. Non-permissions issues (for example hardware or new-laptop problems reported in the same ticket) were routed to the appropriate procurement/issuance or hardware support process rather than the site-permissions workflow.

The outdated course title in the Competency App Preferences was corrected: the responsible team replaced the label shown as "Computertraining" with the current title "Digital Skills" in the preferences UI and applied the change in the app. Separately, a report described that preferred course locations on the mypreferences preferences page failed to persist when users attempted to save them; that issue was triaged to frontend and backend teams for investigation (no resolution recorded in the ticket).

Support confirmed the WhatsApp Business (WAPP) app was running the latest version and that no local error codes were present. The persistent chat-loading and message-loading failures could not be resolved locally. The incident was identified internally as a known/widespread WAPP bug (referenced in an internal Teams post titled "BUG: WAPP Funktionalität"). The ticket was escalated to the specialist team, tasks were assigned (Dana), and incident communication occurred via Teams. The user was given WhatsApp Business Support contact (smb_web@support.whatsapp.com) and reached out to vendor support. No further technical remediation steps were documented in the ticket.

The issue was resolved by changing the Universal Print selection/filter from a specific room to the building-level/location entry (for example, selecting "Frankfurter Allee 73"). Choosing the building-level location expanded the available printers for the floor and revealed hallway devices such as the RICOH MP C3004, allowing the user to select and print to the desired device.

Support determined TEAQ (Standalone) was not managed by central IT and referred requesters to the TEAQ support team. Reporters were given the TEAQ support email (support-teaq@iu.org) and, when applicable, the CareerPartner Jira Service Desk portal for TEAQ (https://careerpartner.atlassian.net/servicedesk/customer/portal/25). Example ticket details: attempts to generate a script PDF via workflow 500 produced the German error "Fehler in Workflow Verarbeitung"; no technical fix was documented in central IT records and the user-facing request was forwarded to TEAQ support. The ticket was later closed after no response was received from the reporter.

Procurement and registration of Parallels Desktop for Mac was completed and a registration link was sent to the requester. After registration the expected and documented outcome was that Parallels Desktop was activated on the Mac, a Windows VM was created/configured, and Power BI Desktop was installed inside the VM so Power BI could run on the macOS device.

Cursor was connected to Linear for the specified team (AI Automation Office) and the Background Agents capability was enabled for that team. The integration was confirmed working for the team and the request was closed as completed.

Tickets were filtered in Jira by the Twilio component and the filtered search results were exported to an XLSX file (produced file: jira-search-1df1770e-7f64-492f-82aa-2a0d0244b610.xlsx). Ticket comments were included where the export supported them (comments are only partially/exportable but were included for bot enrichment). The resulting file was sent by email to the requester.

Attempts to contact WhatsApp by email did not elicit a response. The user instead used WhatsApp's in‑app support (the 'Contact Support' chat accessed via WhatsApp's Help/Help Center) and, after interacting with support through that chat, regained access to WhatsApp on their device. As a contingency, a replacement phone number (new eSIM) was prepared and shared in case in‑app support had failed.

DokGen document output was adjusted to prevent unintended documents from appearing on student paperwork. For DS transcripts, the module PRAXP7 (Praxisbericht VII) was excluded from Zeugnis output; the change was deployed and verified so PRAXP7 no longer appears on generated DS/Zeugnisse. Separately, the intake/termination printing issue was resolved by updating the Document Generator study-program configuration to disable printing of the Exmatrikulationsbescheinigung (Exma) for the affected study program; the configuration change was applied and it was confirmed that Exma is no longer printed for that program.

Two distinct root causes were observed and resolved. In cases where a single PDF was corrupted, replacing or opening a non‑corrupt document restored Adobe Acrobat Reader/DC Pro digital signing and countersigning; no licence or Company Portal changes were required. In a separate incident after an Adobe update, remote support performed uninstall/reinstall of Adobe Acrobat DC Pro (TeamViewer/Teams) but signing remained unavailable; the defective workstation was exchanged and signing functionality was restored after the hardware/workstation replacement.

Support closed the visible stuck WhatsApp session instances and requested session SIDs to identify remaining duplicates. The support team subsequently closed the remaining stuck instances individually, resolving the duplicated/stuck inbox entries.

Support confirmed that PMS and ConnectedWare were operated by a different, owning support team and that IT staff did not have access to perform system-side troubleshooting. Incidents that involved missing search results or element-creation failures (including "out of memory" errors) were not resolved by IT; users were routed to the owning PMS support. Users were advised to open a request via the Career Partner service portal (URL provided in previous responses) or to contact the PMS team directly at pms-fernstudium@iu.org. In at least one case IT staff requested clarification from the PMS team but closed the ticket without applying a technical fix from IT.

IT Support restored the lecture plans in the scheduling/timetabling service and the web portal; after the lecture-plan data was restored the timetable entries were displayed again. No detailed remediation steps were recorded in the ticket.

Multiple incidents involved EPOS refusing UI changes across different profile areas. One incident was resolved when an administrator updated a student’s recovery e‑mail via Roles & Permissions; the admin change saved successfully and the reporting user confirmed the update. In another case, EPOS support determined that stored student e‑mail addresses were managed in the customer profile (Kundenprofil) and that editing the address via User Management triggered permission-related save failures; resetting credentials via EPOS remained possible while direct edits in User Management failed. A separate incident produced repeated HTTP 403 responses when searching for the “Mitgliedsbescheinigung der Krankenkasse”; the user’s permissions and session state were verified, logout/login and browser restart did not help, and the issue was escalated to the EPOS team with no documented resolution. A further incident reported that entries for Anerkennungen (credit recognitions) could not be recorded in the student Notenblatt; that issue was escalated to the specialist team and the ticket was later closed as an outdated request with no technical fix documented. Collectively, these cases showed EPOS refusing UI saves for multiple field types (emails, recognition entries) or returning 403s for searches, with outcomes ranging from successful admin-side updates to escalation without documented root-cause resolution.

Investigators confirmed the course top/overview graphic was a static image and the green checkboxes in the tiles were Moodle's user-managed progress markers (personal tracking) not linked to the course-level completion or onboarding notification system. The user’s actions were verified but were not considered course completion by the onboarding automation because those checkboxes did not update the server-side completion status. The user was informed of this distinction and that the onboarding notification had been triggered by the course-level completion settings rather than the personal checkboxes.

Support verified that message processing worked correctly and that the available template constrained message structure. The resolution used the 'Deutschnotification' template (which contained only the greeting 'Hallo' and closing 'Tschüss') and edited the free-form text between them to produce an appropriate reply. The case was closed after confirming the template workaround allowed a compliant, editable response.

Support confirmed this was expected POB behavior. Tasks delivered via Push were opened in preview mode and required manually clicking the green 'Start' button; tasks not delivered via Push started immediately (auto-dial). FUPs that were currently active executed immediately and could not be deleted or modified; the 'Actions' (X) control appeared only for tasks scheduled for future execution. No system errors were found and the behavior was communicated to the user.

Support requested the workstation's Systeminformationen (computer name), generated temporary administrator credentials, and sent them to the user by email. The temporary password was issued with a two‑day validity period and was re-sent when the user reported they had not received the first message. The credentials allowed the installation to proceed and the ticket was closed.

Support confirmed that the device remained registered but the playlist for the affected screen had been deleted. The missing playlist was recreated in viewneo for the identified screen ('Potsdam 1OG (corridor)'), restoring the intended content and display. The ticket was closed after verifying the screen displayed the recreated playlist.

Investigation showed the Competency App displayed one entry per programme booking recorded in PMS for the same course; this was a designed behaviour rather than a UI bug. Support confirmed the duplicate rows originated from multiple programme enrollments in PMS and advised use of the MyCourses programme-selection filter to restrict the displayed list to a single programme context for tutors.

DokGen/CARE Zeugnis outputs were corrected by fixing the underlying data mappings: the duplicate Bachelor‑thesis grade mapping was removed, the non‑transcript Praxisbericht 7 module was excluded from the Zeugnis data feed, and the English translation entry for 'Bachelorarbeit' in CARE was updated so English certificate outputs showed the proper translated term. A separate OWB certificate instance with a duplicated module and an incorrect overall grade was handled by the Fachteam, who investigated and corrected the certificate output (the duplicated module was removed and the overall grade was corrected); the OWB ticket did not document further technical root‑cause details.

The DokGen templates were updated so the date field mapping points to the booking's exam date instead of the system/today date. After the template field mapping change the generated certificates showed the recorded Abschlussprüfung date.

The root cause was that Calendly had not sent or had failed to deliver the confirmation email for the created location addresses. A project manager escalated delivery; an administrator (Albina) intervened to ensure Calendly re‑sent the confirmation email and that it reached the user's inbox. Once the confirmed email arrived the user completed the confirmation and was able to create appointments.

The vendor (Simovative) applied a permanent fix in the scheduling system that restored the lecturer auto‑fill and selection behaviour for the affected lecture series. After the vendor fix the Lecturer field populated correctly and term creation resumed normally.

Support confirmed they handled only account setup and could not change the portal behaviour. The user was directed to raise the issue on the SalesTech board (the owning Jira project) and provided the appropriate bug reporting links so the product/board owners could investigate and restore the previous template-replacement behaviour.

The service provider investigated the VM IUGAZU1UiPath2 and determined the scheduled storage‑cleanup automation had failed. They performed a manual cleanup to remove excess files from the directory consuming the space, freed disk capacity on the VM, and restored/restarted the storage‑cleanup automation (Automation for Jira). Subsequent runs of the cleanup automation were confirmed to be running and additional free space was available.

Support copied the requested SharePoint page into the requester’s SharePoint space and deliberately did not add it to the site navigation. The missing FAQ questions were traced to an absent site library referenced by the page’s FAQ/web part; once the missing library was recreated/added in the destination site the FAQ content became visible. No other changes were required.

The vendor (Simovative) applied server-side adjustments/patches to the scheduling system which corrected the modal behaviour so planning groups remained visible and could be added in the 'Create appointments' dialog. After the vendor changes were applied the user was able to create appointments for the lecture series as expected.

Support reproduced the symptom with the user, confirmed sign-in/out and bulk-download functionality, and verified the 404 occurred only for individual report downloads. Because the tool was managed outside central support, the case was escalated and referred to the Lead Transfer Tool owner for further investigation and remediation.

Investigators confirmed the display logic merged same‑date RRMP and CMP2 registrations which produced a merged/ambiguous CeMAP view. The MyLIBF display logic was updated to present two distinct CeMAP entries (with unit/module names distinguishing old vs new versions), and the affected account was verified to show separate, clear records.

Support added the renamed/new product (formerly 'CertPay') to ICC Indonesia's allowed product list in the payer configuration. After the product was added to the payer's permitted products the registration error cleared and the previously blocked CertPay registrations could be cancelled; the bulk registration completed successfully.

The infrastructure team restored the mail‑delivery/email‑ingestion pipeline into OTRS. Once ingestion was reconnected, queued/held emails were gradually delivered into OTRS and converted into tickets; as those tickets populated, the previously hidden queues reappeared in agent views. The incident resolved after normal mail flow resumed and backlog processing completed.

The project was placed on hold and no platform was deployed. Before the hold, consultants produced a recommended approach and a preparatory checklist for implementing a Jira Service Management project (also noting Freshdesk, OTRS and Atlassian service portal as alternatives). The deliverables included a suggested project name/description template, an agent‑user list for license planning, identification of the existing incoming email address and portal endpoint, email‑to‑ticket routing considerations, and notes on handling/classifying sensitive submissions to inform later configuration and compliance decisions.

The Application Request was reviewed and the request to change the cost center was declined; no cost-center update was applied to the existing request. The ticket was closed without further changes to the financial coding (the requested CC21205 was considered but not committed).

Support forwarded the issue to the specialist reporting team and provided suggested contacts for BringAFriend and PowerBI matters (including Nadine Seifarth and marigona.nimani@iu.org). The requester located and contacted an appropriate specialist and the support agent confirmed the contact handover; the ticket was closed with the issue referred rather than fixed within central support.

The request was escalated to a specialist for advisory support. A named specialist (Vincent Stolzke) offered to review Twilio‑based options and invited the requester to discuss channel architecture and operational considerations via Microsoft Teams. The specialist handover and offer to consult were recorded and the ticket was closed.

Support determined that management of discount codes and promotion configuration was outside IT's remit. The user was instructed to raise the issue with the IU Meldeportal via Jira Service Management (the team that owns the promotion/discount system). The ticket was closed as 'Won't Do' by IT with no further action recorded.

The extraction errors stopped after a 'temp' directory was created under the user's profile (e.g., C:/Users//temp). The QBEAM Visual Basic extraction process expected that per‑user temp folder to exist; creating the folder allowed the extraction to complete successfully.

Support advised that the Examination Office (Prüfungsamt) is responsible for exam topics, assignments and the locations of exam materials, and that the user should contact them to determine where the exams are held or to request assignment details. As an alternative, the user was directed to the external‑lecturers Service Portal (Jira Service Management) if the Examination Office could not resolve the query.

Identified as a product‑mapping/configuration gap: the new product code (CPCM) had not been included in the payer PA1538 (ICC Indonesia) allowed‑products list. The case was resolved by contacting Finance and asking them to add/map the CPCM product code to the payer configuration previously covering CertPay; after Finance updated the payer record the bulk registration could be completed and the payer was chargeable for CPCM.

Support verified that permissions were correctly set and that colleagues outside the user's team could access the catalogue. Users were advised to clear browser cache/cookies and retry; in at least one case the page began working again without any user action. A related Self Service+ report was treated as a duplicate and closed without configuration change. The incidents were recorded as transient access/browser-related presentation issues rather than permission denials.

The problem was linked to the user's replacement hardware and overall device performance rather than a reproducible Teams service bug. A planned computer replacement (rechnertausch) was scheduled and the ticket was closed in that context. Prior troubleshooting suggestions (uninstall/reinstall Teams) had been noted but not applied before the decision to replace the device.

The request was handled as an application managed outside central IT: support informed the user that Prezi is owned by the Lehrformate team and provided the Lehrformate contact (lehrformate@iu.org) plus an intranet introductory course link. The user was instructed to contact Lehrformate to obtain the Prezi app for Windows and request training or onboarding documentation.

Support confirmed the iPad had been reset during the update (device serial GL200H9F2V), which removed files stored in the local 'On my iPad' location. Attempts to reinstall Acrobat Reader and repeat the iOS update did not stop the app from closing and did not recover the missing files. Because the files were only stored locally on the device (not in OneDrive/iCloud backups), no recovery from the device was possible and the case closed without data restoration.

The ticket recorded that a discrepancy existed between Jamf Cloud device assignments and INV360 records for the affected devices (examples: FFMG9PL4PLJQ and F39GV2XGG4). The case was set to Done with no technical remediation steps or sync-log analysis documented in the ticket notes, so no documented fix or root-cause was recorded in the corpus.

Support uninstalled the affected Adobe Reader installation and performed a fresh reinstall of Adobe Reader. After the reinstall the crashes and hangs stopped and the application remained stable in subsequent use.

Support advised that session rescheduling was controlled by the course administrator and could not be changed from the learner UI. The user was directed to contact the course administrator so the administrator could review and adjust the course's rescheduling/assignment settings or available sessions.

The case was escalated to the assessment-tool specialist team for investigation. The ticket was assigned to the specialist (Denise Sentner) and the reporter was advised to contact assessment-tool-operation@iu.org for specialist follow-up; further technical analysis was deferred to the assessment-tool team.

The issue was resolved by the application team and the ticket was marked as fixed by Anton Stangl on 2024-08-01 14:53. No additional remediation details were recorded in the ticket.

Support escalated the issue to the specialist team for deeper investigation and informed the user that specialists would follow up. No technical remediation steps were documented in the ticket at time of closure.